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SVSTFMS AND METHODS FOR If^ TiVXCmG MEDIA COMPONENTS 

TFrHNTCAL FIELD 

[0001] The described subject matter relates to electronic computing, and 
more particularly to systems and methods for locating, configuring and interfacing 
media components. 

BACKGROUND 

[0002] Media content has traditionally been distributed using equipment and 
protocols that are application-specific, and in some cases proprietary. For 
example, video content has traditionally been encoded in an analog format and 
distributed over television networks, cable networks, satellite networks, and video 
cassette tapes. Special purpose capture and transmission devices are required to 
generate the content. Sunilarly, special purpose receivers and display devices are 

required to access the content. 

[0003] The widespread digitization of media (mcluding multimedia) 
content, especially by the consumer segment, coupled with the growth in digital 
communication networks and easier methods to transfer digital content is changing 
die nature of media content deUvery and usage. Media content can now be 
captured and encoded in one or more of a pluraUty of digital formats (e.g., MPEG. 
Windows Media Format, VCD, etc.) distributed over digital networks such as the 
internet or on digital media and accessed using general purpose computing 
equipment or special purpose equipment. 
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[0004] Digital computing devices play a central role in digital media 
production, encoding, distribution, and display. Microsoft Corporation of 
Redmond, Washington, USA, has developed a set of technologies to facilitate the 
use of digital media and the integration of digital media processing components 
(both hardware and software) with personal computers. MICROSOFT 
DIRECTSHOW is a digital media streammg architecture designed for digital 
audio, video and other types of digital data. DIRECTSHOW provides a high-level 
application model that enables independent hardware vendors (IHVs) and 
independent software vendors (ISVs) to develop streammg media applications that 
combine and use components from possibly different vendors and run on 
computers using the WINDOWS brand operating system. 

[0005] Additional infrastrucmre to faciUtate the integration of digital media 
components is desirable to faciUtate continued development in the digital media 
marketplace and to increase the flexibility that users and developers have to create 
innovative uses of those components. 

SUMMARY 

[0006] Implementations described herein provide an environment in which 
digital media processing components such as, e.g., encoders, decoders, 
demultiplexers, multiplexers, packetizers, can report information about their 
capabilities and expose standardized configuration interfaces to applications that 
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might require the services of the components. In addition, standardized lists of 
configuration parameters, capability requirements and configuration semantics 
(collectively referred to as -profiles') can be provided to appUcations to aid in the 
automation of discovering and configuring of such components to perform 
common user tasks. The profile faciUty removes the need for task-specific 
knowledge to be embedded in applications. The profile information can also be 
updated or corrected vrittiout the need to modify every application which uses die 
profile. 

[OOOTl For example, if an appUcation would like to perfonn a task (e.g. 
■DVD media encoding'), it could look up flte profile for die task (e.g. WD 
encoding') and use tiie contents of die profile to find out what components need to 
do to perform tt,e task (e.g., -DVO encoding') and how to configure d,e 
components to perform tire task (e.g., "OVD encoding'). Tie application does not 
need to know ti,e specifics of flte task to accompUsh it It only requires an 
indication to which ptofile to use (i.e., eiflier a buUt in reference or it may request 
the user to select a profile). At a later point in time, a problem discovered in fl.e 
profile may be conected without requiting every appUcation performing die task 
(e.g., 'DVD encoding") to be modified. 

[0008] In operation, an appUcation in need of digital media services can 
search a register of profiles and a register database of digital media components 
installed on a particular computing device (referred to as die 'component 
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register-). Tl.e component register can be searched without instantiating (i.e., 

■opening-) » ""^"^ '^^'^ 

infonnation describing a component's capabilities (referred to as the component's 

•capabiUty Usf). Tte comtK>nent register and each of ti>e component's capabiUty 
Usts can be used to determine whether tite services indicated in the profile are 
available from inst^dled digital media components. Also provided is an 
Application Programming Interface (API) ^ -bles appUcations to interface 
„iU. and configure digital media components from disp^» ^-V^ vendors. 
,n an exemplary implementation, a method of selecting at least one digital media 
oom^nen, to construct a device that accomplishes one or more tasks identified in 
a profile is provided. ^ me^od comprises retiieving, from Ure proftic at least 
one required capability for i«rforming ti« selected task, selecting, from a 
component register, one or more component entries witi, capability lists that 
include ti>e reqmred capabiUty. and instantiating one or more comments 
corresponding to die selected entries. 

[00(»1 In another exemplary implementation, an apparatus comprises a 
pr<^sorandamemorymodu,econnectedto.heprocessor. The memory module 

. .(.a encoded in the profile) operative to configure 
comprises logic instructions (e.g., encodea in mc p 

«,e processor to retrieve, from a profile, at least one required capability for 
performing a selected task, select, from a component regist«. one or more entries 
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^ include capabiUt, Us. ««. includ. the requi^d oapabUity, and — . one 
or more eomponents corresponding to the selected entdes. 

tOOlOl in another exen^lary implementaticn. a method of interfacing digital 
components on a computer-based processing device com^ constructing 
. component register with entries having capabiUt, Usts of digital medta 
oomt^nenu accessible to the computer-based processing device, and. in response 
,are<,.estfromanappUcationfordigitalmediaservices,searching.hecapabmty 

Usts for a component capable of providing the requested service. 

1001 11 in another exemplary implen^ntadon. a method of interfacing digital 
n^. components on a computer-based prc^essing device comj^ses constructing 
a component register containing capability lists of digital media components 
accessible to the computer-based processing device. At least one UsUng m d.e 
oapabiUty Usts comprises a fnst data field that identifies the digital media 
component, a second data field that identifies a firnction performed by the digttal 
n^edia component, and a third data field that identifies one or mo« operational 
palters associated fimction identified in the second data field. In addition a 
^fae register is constructed. At least one rec»d (i.e.. profile) in the profile 
register represents a digital media fimcUon. The record comprises a data field 
having one or more operating paran^ters associated with the digital medra 
function, m response to a request from an appUcafion for digital media services. 
tt,e profile regUter is searchedforarecordthatco^ponds to drerequestedmedra 
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^.e, ^ the capabUity regi..r is .arched for a component capable of 

providing the requested service. 

[00.2] in anomer exen^lary i,npleme»«>tion. a meUKxl of in« ^igiml 
components on a con^».erW processing device is provided. A 
con^nent register comprising a. ,eas. one eniry including listings of capabiUties 
of digital mediacont^nenu accessible to*econ,puter-basedprocessingdev.ce.s 

constructed. At least one Usting comprises one or more data fields, including a 
data field that identifies a function performed by a digital media component, 
an. a second data field that identifies one or more operational parameters 
associated with a function identified in d.e first data field. A profile register 
comprising at least one recordrepresentingadigitalmediafunctionis constructed. 

T^e record comprises a data field having one or more operating parameters 
associated «d, the digital media fimction. In response to a request ftom an 
appucation for agital media services, the p^file register is searched for a record 
tt,at corresponds to the requested media service, and Ute component register ts 
searched for a component capable of providing the requested service. 

100131 in anoflter exemplary implementation, a method of assembling a 
.opology of digital media components on a computer-b^ processing device is 
p^vided. The method comprises reading lists of capabiUties from a i«.file 
agister, searching a component register for entries containing the capabiUties 
indicated in the profileregist«,andreiectingcom^nentsd,atlacK the capabilities 
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indicawi in the profile regUt«, or that have capabUife incompatible with the 
capabiUlies in the profile register. 

[0014] In another exemplary implementation, a method of assembUng and 
configuring a topology of digital media components on a computer-based 
processing device is provided. The method comprises using a profile struch»e and 
one or more associated capaWUty Usts to select a component, instantiating the 
selected component, applying a profile to the selected component, and logically 
connecting the component to one or more additional components. 

[0015] In another exemplary implementation, a method of configuring a 
topology of encoding and multiplexing digital media components on a computer- 
based processing device is provided. A profile is searched for a multiplexer 
subprofile configuration, and a component register is searched for a multiplexer 
object compatible with the multiplexer subprofile. A multiplexer is instantiated 
and configured by applying U,e subprofile configuration settings using an interface 
API. The multiplexer is comiected to an output of a content source. For each 
input stream of fl,e mdtiplexer, the profile is searched tor an encoder subprofile, 
U,e component register is searched tor a multiplexer object compatible witi, ttte 
subprofile, and the encoder is configured by applymg ti,e subprofile configuration 
settings using an interface API. The encoder is comiected to the multiplexer. 

tOOiei In anodier exemplary implementation, an API ttiat implements a 
pluraUty of meti>ods tor controllmg one or more devices via a plurality of contiol 
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identifiers is provided. The conm>l identifiers correspond to one or more 
configuration settings that have a defined dependency ordering ti«. can be 
expressed as a directed aeycUc dependency graph. The configuration settings are 
structured such that changing a parameter causes a component to reconfigure one 
^ more dependent settings, and high-level configuration settings can be modified 
independent of a low-level configuration setting. 

BPipg nR<!rRIPTI">' SWINGS 

[00171 Fig. 1 is a schematic Ulustraflon of an exemplary computing device 
tt»t can be utilized to implement one or more computing devices in accordance 

with described implementations; 

[0018] Fig. 2 is a high-level schematic illustration of a software architecture 

for interfacing with digital media components; 

[0019] Fig. 3 is a schematic illustration of an exemplary DIRECTSHOW 
filter graph for a hardware capture/encoder application; 

[0020] Fig. 4 is a schematic depiction of a portion of a filter graph for a 
software implementation of a capture/encoder application; 

[0021] Fig. 5 is a schematic depiction of an entry in a capabiUty list; 
[0022] Fig. 6 is a flowchart iUustrating operations to enumerate the 
capabilities of a digital media component; 
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[00231 Rg. 7 is a Howchart of operations an application may execute to 
interface a pluraUty of digital media components to constn-ct a device that 

performs a task; 

[0024] Fig. 8 is a schematic depiction of an exemplary mapping of profiles 

onto capabilities; and 

(00251 Rg. 9 is a schematic depiction of applying a profile to an enccKhng 

topology. 

[00261 Exemplary meti.ods. systems, and devices are disclosed for 
interfacing media components. This document describes an exemplar, computer 
system on which tt,e systems and method described herem may be implemented. 
Following tite description of the computer system is a description of exemplary 
software architectiue. The methods described herein may be embodied . logic 
i^^ctions on one or more computer-readable media. When executed on a 
p^sor. the logic instructions cause a general purj^se computing device to be 
p„grammedasaspecial-p»r^semachineti,atimplementsti«describedmeti,ods. 



Firi^ni plarv C »"^P"*^"F System 

[00271 Big. 1 shows an exemplary computing device 130 *at can be ntiUzed 
,0 hnplement one or more computing devices in accordance witi, the descrit^d 
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.^bc^ent. computing device 130 can be utiUzed to i»p.e,ne.. various 
toplementations in accordance with described embodiment. 

100281 computing device 130 includes one or more processors or 
processing uni. 132, a sys.m memory 134, and a bus 136 U,a, couples various 
sys^m components including the system memory 134 to processors 132. The bus 
,36 represents one or more of any of several types of bus structures, including a 
memory bus or memory controller, a peripteral bus, an accelerated graphics port, 
^ a pr^essor or local bus using any of a variety of bus architectures, "n-e 
system memory 134 mcludes read only memory (ROM) 138 and random access 
memory (RAM) 140. A basic input/output system (BIOS) 142. containing the 
basic routines that help to transfer mformation between elements wititin computing 
device 130. such as during start-up, is stored in ROM 138. 

[0029] computing device 130 further includes a h^ disR drive 144 for 
^gfromand writing .oaharddisk(notshown).amagneticdislcdrivel46for 

^ding from and writing to a removable magnetic dislc 148, and an optical disk 
drive 150 for reading ftom or writing «. a removable optical disk 152 such as a CD 
ROM or oUrer optica, media. The hard disk drive 144. magnetic disk drive 146. 
and optical disk drive 150 are comrected to tite bus 136 by a SCSI interface 1 54 or 
some other appropriate interface. Tlte drives and titeir associated computer- 
^ble media ^vide nonvolatile storage of computer-readable instrttctions, data 
s„, program modules and oUrer data for computing device 130. Aititough 
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*e exemplary e„— . described herein employs a hard dis., a — 
^agneUc di.R 14S and a re„K,vab.e opUoa. dis. 152, i. should be app«cia.ed by 
^oses,ciUedintt.ear.*a.o4ert,pesofco,np>..«.readab.en,ediawhichca«store 

aau ma. is accessible by a co»p»«r, such as nu.gnetic casseaes, flash memory 
cards, digital video dis,.. random access memones (RAMs), read only memories 
(ROMS), and me Uice, may also be used in a.e exempli operating environmen,. 

[00301 A number of program modules may be stored on .he hard disk 144, 
^^etic disk 14S, opUcal disk 152, ROM 13S, or RAM 140, including an 
oper^ng system 158, one or more application programs 160, other program 
,„«h,lesl62,andprogramda.al64. A user may enter commands and informauon 
into computing device 130 through input devices such as a keyboard 166 and a 
Minting device 168. Other input devices (not shown) may include a microphone, 
jo^tick, game pad, satemte dUh, scanner, or the like. l.ese and other input 
^vices are comtected to *e processing unit 132 through an interface 170 coupled 
.0 the bus 136. A moni«>r 172 or other type of display device is also com.ec.ed to 
bus 136 via an interface, such as a video adapter 174. In ad^tion to the 
monitor, personal computers typicaUy include other peripheral output devices (not 
shown) such as speakers and printers. 

[0031] computing device 130 commonly operates in a networked 
enviromnen. using logical connections to one or more remote computers, such as a 
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oompu»r. a server, a ro»»r, a network PC. a peer device or other commo. ae^vork 
node, and typically include, many or aUoftheelementsdeseribedaboverelative to 

computing device 130. although otJy a memory storage device 178 has been 
illustrated in Fig. 1. logical connections depicted in Fig. 1 include a local ^ 

««t,i,orif rWAN^ 182. Such networking 
network (LAN) 180 and a wide area network (WAM) 

lo^o in nffices enterprise-wide computer networks, 
environments are commonplace m ottices, enierpn 

intranets, and the Internet. 

[0032] When used in a LAN networking enviromnent. computing device 

,30 is connected to the local network 180 through a network interface or 
184. When used in a WAN networking environment, computing device 130 
typically includes a modem 186 or otiter means (or estitbUshing communications 
over tite wide area network 182, such as the Internet. The modem .86. which may 
be internal or external, is com.ec,«l to the bus 136 via a serial port interface 156. 
U a networked environment, program modules depicted reUtive to the computing 
device 130. or portions ti^reof. may be stored in the remote memory storage 
^vice. It will be appreciated that the network connections shown are exemplary 
.nd other means of estabUsbing a communications link *e computers 

may be used. 

[0033] Generally, the data processors of computing device 130 are 
p^g^ed by means of instructions stored at different times in tire various 
computer-readable storage media of tite computer. Programs and operating 
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systems are typicaUy disributed. for example, on floppy disks or CD-ROMs. 
From d,ere, U>ey are installed or loaded into a.e secondary memory of a computer. 
At execution, they are lo^ at least partiaUy into the computer's primary 
electronic memory. The invention described herein includes these and other 
various types of computer-readable storage media when such media contain 
instructions or programs for implementing the steps described below in 
conjunction wiU, a mic«,processor or other data processor. Tl.e invention also 
includes tite computer itself when programmed according to the me^ods and 
techniques described below. 

RTtmolarv <:~f"»»"- Arrhitecture 

[0034] For purposes of iUustration. a description is provided of an 
exemplary implementation of an enccKier component used in the context of a 
MICROSOFT DIRECTSHOW digital media streaming architecture. However, flie 
feamres and operation described herein are not limited to encoder components, 
nor are they Bmited to fl.e MICROSOFT DIRECTSHOW digital media streaming 
architecmre. Rathe, ti,e features and operations described herein are generally 
applicable to digital media components operable in a digital medU architecture that 
executes on any operating system including UNK operating systems and its 
variants, including Linux operating systems. 



Lee & Hayes, PLLC 



13 



MSl'POWS 
304855.01 



[00351 Fig. 2 shows a software architecture for interfacing vrith digital 
„edia components. Referring to Fig. 2 an apphcadon 210 mterfaces with a digital 
„edia component 225 thr^gh an API 215. AppUcation 210 may be any 
apphcation that ntiUzes the services of a digital media component. TVpical 
appUcations include a compact disk (CD) player or recorder, a digital video disk 
(DVD) player or recorder, or any other appUcation that utilizes digital medi. 
AppUcation 215 also mtertaces with register 220. which includes a profile register 
230 and a component register 235 that contains capabUity Usts 245 within each 

component's register (e.g. 240). 

[0036] Profile register 230 stores a pluraUty of profiles. Each profile m 

profile register 230 is a fixed Ust of configuration settings ti,at accompUsh a task. 

For example, a profile may define tite settings for low-<,uaUty DVD encodmg. 
This profile would include the video and audio encoder settings to produce a low- 
bandwidth DVD compliant stream. Additional profiles may define ti,e settings for 
high-quaUty DVD encodmg. MPEG enc<xUng, etc. CapabiUty information in 
capabiUty Hsts such as 245 comprises a Usting of the capabihties of each digital 
„«aa components available for use by application 210. Profiles and capabihties 

are discussed in greater detail below. 

[0037] Fig. 3 shows an exemplary DIRECTSHOW filter graph 300 for a 
hardware implementation of a capture/encoder. Each of the components of filter 
g^h 300 corresponds to a digital media component 225 identified in F.g. 2. The 
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fiUer graph comprises a crossbar switch filter 310 ma. is configured to select an 
„„q,„t of a digital media device from which a media stream may he received. The 
ou.pu.of the crossharswitchSlOis input toacapt«eproxyfllter315 that controls 

U.e hardware tha. digitizes video and audio signals. The cap.u« proxy filter 315 
outputs an uncompressed video signal and an uncompressed audio signal. These 
signals are input » an encoder proxy fito 320 that encodes the agital audio 
signals to generate an output comprising compressed video and audio signals. 

[00381 in an exemplary implementation, the output of encoder proxy filter 
320 may he subjected to subsequent downstieam processing to generate an MPEG- 
2 strean. m to embodiment, the output of encoder proxy filter 320 would be 
input to an MPEG-2 packetizer, which segments ti>e compressed digitized video 
and audio stieam into packets compatible witi. the MPEG-2 protocol. These 
packets are titen forwarded to an MPEG.2 multiplexer, which multiplexes the 
packet stieams with other packetized audio and/or video streams to generate an 
MPEG-2 stream. Tlte MPEG-2 stieam may be transmitted across a suitable 
«„„missio„ network and decode by a suitable appUcation at the receiver. 1. wiU 
be apprecia.ed tita. ti>e output of encoder filter may be processed in.o any number 
of digiml media formau (e.g., MPEG WMF, VCD. PVR, e,..). Tl-e multiplexer 
^, be anotiter hardware component titat outputs a MPE02 multiplexed stream. 

[00391 TTie fUters 310. 315. and 320 are insBntiated in the user mode of the 
operating system of the computing device on which the filter graph 300 is 
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toplemented. In an exemplar, implementadon. a series of corresponding 
AVStream filers. MimDriver Capmre Hlter 350 ^ MiniDriver Encoder Filter 
355, are implemented in the kernel mode of the operating system of the operating 
system of the computing device on which the filter graph 300 is implemented. 

[0040] FUter graph 300 comprises a codec API ptoxy 325 a>at mterfaces 
with the encoder proxy filter 220. The encoder API proxy 325 is a plug-in tiu. 
ttanslates the encoder API caUs into properties destined for an AVStream encoder 
filter and corresponding topology nodes. Associated with the devices, is a profile 
330 fl>at indicates configuration parameters to be used witi. ttte encoder proxy filter 
320 and the codec API proxy 325. The profile's usage will be discussed in greater 
detail below. The device's registration adds entries to tire component register. In 
addition, it adds capabiUty Usts to the registration information. 

[0041] Hardware implementations used in a media context other than 
DIRECrSHOW such as, e.g.. Media Foundation, utiUze eifl,er a source, transform 
or sin. ti,at wraps tire encoder subsection of U.e DirectShow encoder graph or a 
different proxy component ti,at .epresents a kernel AVStream filter/chain as a 

DM0 or similar entity. 

[0042] A software implementation of a capMre encoder appUcation may 
have substantiaUy tite same architecmre as iUustrated in Fig, 3, except that ti,e 
filter graphs may be implemented as DirectX Media Objects (DMOs), Media 
Foundation Transforms, or oti,er abstraction objects rather ^ proxy filters. Fig. 
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4 is a schematic depiction of a portion of a fiUer graph for a softivare 
implementation of a captive/encoder application. Referring » Rg. 4, a software 
i„^,emen.tion would include an AA. capti^ device 415, a DM0 420. and a 
p„r.,e 430. A/V capti-re device 415 corresponds ,o fl>e captive filter 315 of filter 
g„ph 300. The outputs of capture device 415 are directed u. encoder DM0 420. 
which corresponds to the encoder filter 320 of filter graph 300. Profile 430 
aescribes configuration settings to be used witi, interfaces with ti,e encoder DM0 



420. 



[00431 AnoUier novel approach to defining the semantics of the 

configuration settings is ti> enforce a rule U.t re,uires configuration senings «, 

have a stiong ordering and a hierarchical dependency relationship. This has a 

significant impact on the design and usage of confirmation setiings. Settings may 

1, organized into a dependency tree such tiuU ti,e higher setiings in the hierarchy 

need to be set before specific lower .eve. settings may be set. Changing a high 
level setting may cause tite component to alter oneormored^ndent setiings such 

*at titey take on vaUd and consistent settings. This ensures tirat devices are in a 
oonsisu^nt state when configured by an app.ication or user and removes ti« need 
to .atomic' operations where multiple setiings are changed at once ti, ensure 
consistency. In addition, tins allows applications u, alter high level settings (e.g. 
bit rate, quaht, etc) wititou. having to know about more enteric, dependent 
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semngs and « that devices are in a consistent state if the, are modified 
simultaneously by more tlian one entity. 



r. ^hllitv Lif ^ romi-""'"' Register 

10044) A digital media component such as an encoder can register a list of 
its high-level capabiUties in cap^iUty lists within the component register 235 (Fig. 
2), which may be implemented as a databa. or another suimble structured memory 
aevice. in this context, the term "capabiUties" can include information such as the 
actions the digital media component can invoice, the name of the vendor or 
^ufacturer of the component, metadata about d,e device, types of media it 
supports, appUcaUons for which it is cerUfied and other digital media components 
with which the component is compatible. 

[0045] Each capabiUty may be identified using a Globally Unique IdenUfier 
(QUID). The capabilities Usts may be stored in a branch of the register, e.g.. as an 
of value names indicated by the capability GUID foUowed by one or mote 
values. By way of example, an encoder capable of both high-quality and low- 
quality DVD encoding may register these capabilities in the register. 

[00461 In an exemplary implementation, capabiUties are stored m a data 
„ using a separate Capabilities identifier (for example, a VTrndoWs registry 
subkey). For example, filter implementers can create a capabilities subkey to store 
tt,e device's capabiUties. TUe capabilities subkey may be stoted with ti« device's 
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filter's data (e.g. FilterData item), and the filter's textual name (e.g. FriendlyName) 
values in the filter's static data. Alternatively, encoder vendors can create a 
reference in the filter's data to indicate the location of the capabilities (e.g. a 
CapabiiitiesLocation key that contams a string giving the location of the 
Capabilities subkey in the register.) to allow sharing capabilities across 
components. In current versions of Windows, Plug and Play (PnP) lacks a 
convenient mechanism for a driver to specify the location of the CapabiUties 
subkey relative to its PnP entry. This problem is solved by specifying that the 
driver's setup files can simply create a capabilities subkey adjacent to the filter's 
FriendlyName. 

[0047] In one implementation, each subkey value may be implemented as 
one of the following: (1) a single numerical value, stored as a DWORD value; (2) 
a GUID, stored as in the string form of the GUID; (3) ratio quantities or numerical 
pairs that represent pairs of values such as width/heights and/or fractional values 
represented as a numerator/denominator, e.g., a data pair of the format 'a, b' used 
to denote that the value should be interpreted as two DWORDs concatenated 
together to form a 64 bit integer, with the value of 'a' being in the upper DWORD; 
(4) arrays of values. 

[0048] In another implementation, each subkey value may be implemented 
as a single numerical value indicating the data type of the value, stored as an 
integer value followed by a texmal encoding of the value. The actual encoding 
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would be obvious to someone skilled in the art; e.g. an integer would be coded as 
textual number, a GUID could be stored as in the string form of the GUID; ratio 
quantities or numerical pairs that represent pairs of values such as width/heights 
and/or fractional values represented as a numerator/denominator (as previously 
described). For unknown types, a binary encoding of the data could be used. 

[0049] In another implementation, the capability's location key could 
indicate the location of an XML file to store a description of the device's 
capability. 

[0050] Fig. 5 is a schematic depiction of an exemplary implementation of a 
component register 500 which encodes capability lists. Referring to Fig. 5, 
component register 500 is embodied as a data structure that may be stored in a 
suitable memory location such as, e.g., the RAM 140 of computing device 130. 
The component register 500 may be implemented as a database, or more simply as 
a logically linked hst. The component register 500 comprises a pluraUty of data 
fields 512-520 that may include an entry that contains enough information to 
identify a digital media component and possibly enough information to instantiate 
the object. The component register is illustrated with five data fields; however this 
number is not critical. Any number of data fields may be implemented. 

[0051] Each data field 512-520 that corresponds to a device is logically 
linked to a collection of at least one subfield 524-538 (i.e. a capabiHties list) that 
includes information identifying a function performed by the device identified in 
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the data field. Each subfield 524-538 is, in turn, logically linked to at least one 

additional subfield 540-562 that includes information identifying one or more 

operational parameters associated with the capability identified in the subfield. 

[0052] Following is an exemplary entry for a filter device identified by the 

FriendlyName "MyFilter". The capabilities list entry for the filter comprises four 

capabilities, identified by GUIDl, GUID2, GUID3, and GUID4. The values 

associated with the GUIDs would be determined by the characteristics of the filter. 

By way of example, MyFilter may be a DVD encoder, and one of the GUIDs may 

specify encoding capabilities of the filter. 

FriendlyName REG_SZ "My filter" 
+Capabilities (subkey) 

GUIDl REG.DWORD Valuel 
GUID2 REG.SZ "Value2" 

GUID3 REG_SZ_MULTI "Value3a", "ValueSb", "Value3c"... 
GUID4 REG_SZ_MULTI "720,480", "320,240", 

[0053] In the context of a DIRECTSHOW application, software filters can 
register directly with the component register. In operation, an application such as 
application 210 retrieves a register handle to read a capabilities subkey using the 
interface on a filter's moniker (a moniker is a reference to a component register 
entry corresponding to the descriptive information about the device, e.g. items 
512-520 in figure 5). 

[0054] Fig. 6 illustrates operations 600 an application may implement to 
enumerate the capabilities of a particular encoder. At operation 610 the application 
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creates a moniker that represents the encoder filter (i.e. obtains a reference to the 
component register's entry corresponding to the encoder filter). At operation 615, 
the application queries the filter moniker to obtain the capabilities of a software or 
hardware encoder from the register. In an exemplary embodiment this query may 
be performed using the DIRECTSHOW IGetCapabiUtiesKey mterface. The 
IGetCapabilitiesKey interface exposes the GetCapabiUtiesKey method, which 
returns a handle to the register key that contains the filter's capabilities Ust. The 
application can invoke the GetCapabiUtiesKey method to obtain the register key. 
With the register key, the application can invoke the RegEnumValue function to 
enumerate the values for the returned key (operation 620). Hardware filters, or 
their proxy filters, can register using .inf register key sections. In this way. the 
register maintains a Usting of the capabiMes of digital media components 
avMlable for use by an application. 



Exemplary Profile Register 

[0055] Register 230 also maintains a profile register 235, which is a fixed 
Ust of profiles, each containing Usts of configuration settings used to accomplish a 
particular task. The profile register 230 may be implemented usmg a data structure 
substantially similar to the data structure used to implement the capabilities 
register 235. The data structure may be embodied as a database, a Unked Ust, or 
any other suitable data structure. 
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[0056] By way of example, there may be a profile that defines low 

bandwidth DVD encoding, which lists all the video and audio encoder settings 

required to produce a low-bandwidth DVD comphant stream, as follows: 

FriendlyName = "LowBandwidthDVD" 

{realtime}="true" 

+ {video encoder GUID} 

"{bitrate_guid)"= 2000000 

" {resolution_guid } "="720,480" 

"Required GUIDS"="{guidl },{guid2}" 
+ {audio encoder GUID} 

"{bitrate_guid}"= 50000 
+ {multiplexer GUID} 

"{max_bitrate_guid}"= 2500000 



[0057] Profiles can be identified by a GUID, which is recorded in the string 
form of a GUID to aid in uniquely identifying them (this is not required in all 
implementations but solves indexing issues for the application). Profiles may also 
include a value that identifies the profile to aid in providing a textual description of 
the profile to a user interface. In Fig. 7, the identifier "FriendlyName" identifies 
the profile as LowBandwidthDVD. Profiles are independent of any particular 
digital media component. 

[0058] Each profile may include one or more subprofiles, each of which is 
identified by a GUID, and one or more parameters, or settings. Subprofiles may be 
assigned to functional categories, e.g., video encoding, audio encoding, 
multiplexing, etc. Settings define attributes of the functionality represented by the 
subprofile. Settings may be apphcation-specific or device-specific. For example. 
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if a single bit rate is specified in the profile, then the specified bit rate will be 
applied to all components supporting the profile. By contrast, if separate video 
and audio bit rates are specified in the profile, e.g., by two separate GUIDs, then 
separate bit rates may be applied to video and audio processing. 

[0059] Each subprofile may also include a "RequiredCapabilities" field that 
indicates which GUIDs are required to be present in the capabilities list for 
devices. Capabilities are represented by GUIDS, so the RequiredCapabilities field. 
Required GUIDS may be used to generate a rejection filter for devices which lack 
required settings for a particular profile. 

[0060] Profiles can also include a 'CriticalSettings' field that an application 
can use to determine which configuration settings must succeed to deem if the 
profile was successfully applied. In some circumstances, failing to set a 
configuration setting may not inhibit the encoder from accon^Ushing the desired 
task. 

Exemplary Application Program ming Tnterface 

[0061] In an exemplary embodiment an application programming interface 
(API) is provided to enable an application to communicate with digital media 
components Usted in the component register, or otherwise registered on the system. 
The API implements methods that enable an application to monitor and/or modify 
the settings of a digital media component. A summary of the methods 
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implemented by an exemplary API for an encoder is encapsulated in the following 
table (collectively known as the ICodecAPI interface). 



Method/Parameters 


Description 


GetAllSettingsO 

pStream[in]: a pointer to the stream 


Saves the current encoder settings to a 
stream. This method enables an 

dppilCallOn 10 paCKdgC a Ulgiiai iiicuxa 

component's current configuration in a 
stream, which can be saved and 
subsequently reinstated. 


GetDefaultValueO 

Api[in]: a pointer to a GUID that 
specifies the parameter 
Value [out]: a pointer to a VARIANT 
type that receives the default value. 


Retrieves the default value for a 
parameter, if one exists- 


GetParameterRangeO 
Api [in]: a pointer to a GUID that 
specifies the parameter; 
ValueMin [out]: a pointer to a 
VARIANT type that receives the 
minimum value of the parameter; 
ValueMax [out]: a pointer to a 
VARIANT type that receives the 
maximum value of the parameter; 
SteppingDelta [out]: a pointer to a 
VARIANT type that receives the 
stepping delta, which defines the valid 
increments from ValueMin to 
ValueMax. 


Returns the valid range of values for a 
parameter. Also retums an increment 
value for a parameter, if one exists. 

- 
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GetParameterValuesQ 

Api [in]: a pointer to a GUID that 
specifies the parameter. 
Values [out]: An address of a variable 
that receives a pointer to an array of 
VARIANT types. The array contains the 
list of values the encoder supports for 
this parameter. The caller may free the 
array by calling the CoTasl^emFree 
function. 

ValuesCount [out]: a pointer to a 
variable that receives the number of 
elements in the array. 


Returns the list of supported values for a 
given parameter. The list is returned as 
a COM allocated array. The array may 
be 


GetValueO 

Api [in]: a pointer to a GUID that 

specifies the parameter. 

Value [out]: a pointer to a VARIANT 

type that receives the value of the 

parameter. 


Retrieves the current value of a 
specified parameter. 


IsModifiableO 

Api [in]: a pointer to a GUID that 
specifies the parameter. 


Queries whether a parameter can be 
changed. Returns a value that indicates 
whether parameter can be changed. 


IsSupportedO 

Api [in]: a pointer to a GUID that 
specifies the parameter. 


Queries whether a given parameter is 
supported. Returns a value that 
indicates whether a parameter is 
supported. 


RegisterForEventO 

Api [in]: a pointer to a GUID that 
specifies the event. 

userData [out]: a pointer to caller- 
defined data. The application receives 
this pointer in the event parameter. The 
appUcation can use this data to 
differentiate events coming back from 
<sPVpral pticoders 


Registers the appUcation to receive a 
specified event from the encoder. The 
application will receive an event 
notification whenever the encoder 
driver sends the event. 


SetAllDefaultsO 


Returns all parameters to their default 
values. 
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SetAllDefaultsWithNotifyO 
ChangedParam [out]: An address of a 
variable that receives a pointer to an 
array of GUIDs, of size 
ChangedParamCount. The array 
contains the GUIDs of the parameters 
that have changed in the encoder as a 
result of this method call. The caller 
may free the array by calling the 
CoTaskMemFree function. 
ChangedParamCount [in]: A pointer to 
a variable that receives the number of 
cicmenis in ine array. 


Retums all parameters to their defauh 
values, and retums a list of the settings 
that have changed. 


SetAUSettingsO 

pStream[in]: a pointer to the stream 


Loads encoder settings from a stream 
and sets them on the encoder. 


SetAUSettingsWithNotifyO 

Api [in]: a pointer to a GUID that 

specifies the parameter. 

Value[in]: a pointer to a VARIANT 

type that contains the new value for the 

parameter. 

ChangedParam [out]: an address of a 
variable that receives a pointer to an 
array of GUIDs, of size 
ChangedParamCount. The array 
contains the GUIDs of the parameters 
that have changed in the encoder as a 
result of this method call. The caller 
may free the array by caUing the 
CoTaskMemFree function. 
ChangedParamCount [out]: a pointer to 
a variable that receives the number of 
elements in the array. 


Loads encoder settings from a stream, 
sets them on the encoder, and retums a 
list of the settings that have changed. 


SetValueO 

Api [in]: a pointer to a GUID that 

specifies the parameter. 

Value [out]: a pointer to a VARIANT 

type that contains the new value for the 

parameter. 


Sets the value of a parameter. 
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SetValueWithNotifyO 

Api [in]: a pointer to a GUID that 

specifies the parameter. 

Value[in]: a pointer to a VARIANT 

type that contains the new value for the 

parameter. 

ChangedParam [out]: an address of a 
variable that receives a pointer to an 
array of GUIDs, of size 
ChangedParamCount. The array 
contains the GUIDs of the parameters 
that have changed in the encoder as a 
result of this method call. The caller 
may free the array by calling the 
CoTaskMemFree function. 
ChangedParamCount [out]: a pointer to 
a variable that receives the number of 
elements in the array. 


Sets the value of a parameter, and 
returns a list of other settings that have 
changed as a result. 


UnregisterForEventO 

Api [in]: a pointer to a GUID that 
specifies the event. 


Unregisters the application for a 
specified encoder event. 



[0062] In an exemplary embodiment, an intennediate layer which we will 
refer to as the 'encapi' layer, implements the ICodecAPI interface by mapping 
Get/Set calls into KsPropertySet calls that are sent to the underlying driver. The 
'encapi' layer implements the more complex functions such as 'WithNotify' or 
change event notifications by using a special series of driver property sets that may 
be used to interface with devices: 

[0063] CODECAPI_VIDEO_ENCODER: Video encoders use the support 
of this GUID (queried by the user-mode KsProperty B ASICSUPPORT) to indicate 
they are a video encoder. The property value (operation data) is of type BOOL and 
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specifies whether the minidriver supports video encoding. A value of TRUE 
indicates that the minidriver supports video encoding. The filter should not support 
this GUID if it is not a video encoder. 

[0064] CODECAPI_AUDIO_ENCODER: Audio encoders use the support 
of this GUID (queried by the user-mode KsProperty B ASICSUPPORT) to indicate 
they are an audio encoder. The property value (operation data) is of type BOOL 
and specifies whether the minidriver supports audio encoding. A value of TRUE 
indicates that the minidriver supports audio encoding. The filter should not support 
this GUID if it is not an audio encoder. 

[0065] CODECAPI_SETALLDEFAULTS: This property is used to 
implement the 'SetAllDefaults' method and will reset all the internal settings of the 
minidriver to their default configurations. A set to this property set is a trigger that 
the device should reset all of its settings to their defaults. 

[0066] CODECAPLALLSETTINGS: This property is used to pass back 
and forth a minidriver-generated block of data. The property value is of type 
PVOID, which is a pointer to a user-mode buffer for the minidriver-generated 
block of data. It is used to instruct the driver to encode all of its configuration 
state into a block of binary data and is used to implement the method 
'GetAUSettings'. 

[0067] On a property get call, if an appUcation makes a property get call 
with a zero length buffer, then the minidriver returns 
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STATUS_BUFFER_OVERFLOW and specifies the required buffer size. If the 
length buffer is non-zero, then the minidriver returns 
STATUS_BUFFER_TOO_SMALL if the supplied buffer is too small for the data 
block. Otherwise the minidriver packs its settings into a data block that can be 
restored later. 

[0068] On a property set call the minidriver verifies the data's integrity and 
checks that the data block size is under the maximum data size. It also verifies the 
CRC and the header length. The minidriver must also cache any changes to be 
propagated for CODECAPI_CURRENTCHANGELIST. The property set call 
with the 'CODECAPI_ALLSETTINGS' parameter is used to implement the 
method 'SetAUSettings'. 

[0069] It is the minidriver's responsibility to add data integrity checks to the 
data, such as a unique GUID to indicate the minidriver generated the data, a cyclic 
redundancy check (CRC), and a header length. The data returned should be 
lightweight and contain only information required to reconstruct the current 
settings. Applications may use this property for multi-level undos, stored with 
their projects, etc. 

[0070] CODEC API_SUPPORTSEVENTS: This property is used to 
indicate whether the minidriver supports user-mode events. The property value is 
of type BOOL, which specifies whether the minidriver supports user-mode events. 
A value of TRUE indicates the minidriver provides support. The minidriver should 
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not support this GUID if it does not support the event mechanism. This property is 
used to implement if 'RegisterForEvent' should be enabled. 

[0071] CODEC API.CURRENTCHANGELIST: This property is used to 
indicate which parameters changed in a previous property "set" call, such as 
CODECAPI.ALLSETTINGS and CODEC API.SETALLDEFAULTS. The 
property value (operation data) is an array of GUIDs. This property is used to 
implement the 'WithNotify' methods by calUng the 'Set' call first, then reading this 
property to pass back the changed setting list to the application. 

[0072] On a property get call, if an application makes a property get call 
with a non-zero buffer size, the minidriver returns 
STATUS_BUFFER_TOO_SMALL if the supplied buffer is too small for the data 
block. If there are no items to return, the minidrivers returns STATUS_SUCCESS. 
Otherwise, a hst of GUIDs is returned. On a property set call, the current list of 
changed GUIDs is reset. 

Exemplary Operatioiis 

[0073] In an exemplary implementation, an application may utilize one or 
more profiles in the profile register 230 and capabilities in component register 235 
to construct digital media devices having a particular functionaUty from the 
various registered digital media components. This is illustrated with reference to 
Fig. 7 and Fig. 8. Fig. 7 is a flowchart of operations 700 an application may 
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execute to interface a plurality of digital media components to construct a device 
that performs a task. Fig. 8 is a schematic depiction of an exemplary mapping of 
profiles onto capabilities. 

[0074] Referring to Figs. 7-8, at operation 710 a request is received to 
perform one or more tasks associated with a particular function. By way of 
example, an application may need to perform real time DVD encoding. The 
request may be generated automatically by the application, or may be generated by 
a user of the application. 

[0075] At operation 714 it is determined whether there is a profile matching 
the requested task in the profile register. By way of example, the profile register 
may be searched for a profile matching the requested task. If there is not a 
matching profile in the profile register, then the process terminates at operation 
716. By contrast, if there is a matching profile in the profile register, then the 
matching profile is selected from the profile register. 

[0076] At operation 7 1 8 the component register is searched for a component 
with a capabilities list having all the required capabilities identified in the 
"RequiredCapabilities" field of the selected profile. In an exemplary 
implementation, the capabilities register may be searched for entries having 
GUIDs which match the GUIDs enumerated in the RequiredCapabilities field of 
the selected profile. If one or more entries in the capability register match 
(operation 720), then the matching component(s) are enumerated at operation 724. 



Lee & Hayes, PLLC 



32 



MS1-J701US 
304855.01 



[0077] At operation 728 the process selects entries having settings that are 
compatible with the settings in the selected profile. If one or more matching 
entries were located at operation 720 and enumerated at operation 724, then 
operation 728 is performed on the set of matching entries. By contrast, if no 
matching entries were located at operation 720, then operation 728 is performed on 
all entries in the capability register which have a function that corresponds to the 
requested function. By way of example, if the requested function is DVD 
encoding, then operation 728 searches all DVD encoder entries in the capability 
register. Entries in the capability register may be considered compatible with the 
selected profile if the settings in the capability register are within the range of 
settings specified in the selected profile. 

[0078] At operation 732 the selected device(s) are instantiated. By way of 
example, in the DIRECTSHOW environment the devices may be instantiated by 
invoking existing interface methods, such as, e.g., the ICreateDevEnum interface. 

[0079] At operation 736 the selected device(s) are connected to other 
selected device(s) required to perform the requested task. By way of example, in 
the DIRECTSHOW environment the devices may be connected by invoking 
existing interface methods such as, e.g., the IFilterGraph interface, the 
IGraphBuilder interface, and the IFilterGraph2 interface. If the search process 
yields multiple components compatible with the profile, then any of multiple 
components may be connected. 
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[0080] At operation 740 the settings in the subprofile of the selected profile 
are applied to the instantiated component. By way of example, in the 
DIRECTSHOW environment the subprofile may be applied by invoking the 
interface methods described above such as, e.g., the SetAUSettings interface or the 
SetValue interface. The 'CriticalSettings' field in the subprofile can be used to 
determine which settings must succeed to constitute a successful application of the 
subprofile settings. 

[0081] Fig. 8 is a schematic illustration of a mapping between the profile 
register and the capabilities in the component register in response to a request for a 
real time DVD encoder. Referring to Fig. 8, the profile register 810 includes a 
plurality of entries 815-825 including an entry for a real time DVD encoder 815. 
The capabilities in the component register 840 includes a plurality of entries, 
including entries for video and audio encoders 845-855. 

[0082] In response to a request for a real time DVD encoder, the profile 
entry 815 is selected. Profile entry 815 lacks a RequiredCapabilities field, so a 
search of the entire capability register is performed to locate entries that have 
settings within the ranges specified in the profile entry 815. Referring to entry 
845, the entry for video encoder KS Filterl is rejected because its maxBitRate 
setting of 200 is less than maxBitRate of 5000 specified in profile 815. By 
contrast, referring to entry 850, the entry for video encoder KS Filter2 is selected 
because its maxBitRate of 10,000 exceeds the maxBitRate of 5000 specified in 
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profile 815. Similarly, referring to entry 855, the entry for audio encoder KS 
Filters is selected because its maxBitRate of 10,000 exceeds the maxBitRate of 
5000 specified in profile 815. Accordingly, video encoder KS Filter! and audio 
encoder KS FilterS are instantiated as digital media components 860 and 865, 
respectively. Encoders 860, 865 may be connected to other digital media 
components, e.g., multiplexers, packetizers, etc., to create a digital media device 
that performs a specific function. 

Multi-Pass Generalization of Exemplary Qperatjons 

[0083] The previously described selection algorithm can be generalized to a 
multi-pass selection algorithm. Each capability listed in the "Required Capability' 
field in a profile is can be treated as a rejection criteria for performing comparisons 
against capabilities Usted in the capability Usts in the component register. If a 
capabiUty is Usted in both the required list and in the capabiUty list and they are not 
compatible, then the component can be rejected for consideration to be instantiated 
to attempt to apply the subprofile settings. 

[0084] If a capability is present in the 'required' Ust but is not present in the 
device's capability list, then no conclusion can be drawn so the device must be 
considered on a subsequent pass. Similarly if no required capabiUties Ust is 
present, then aU devices must be considered to be instantiated. 
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[0085] The algorithm assembling the components may attempt to assemble 
those components with exact capabiUties matches first, followed by another pass 
including components that did not have the required capabilities mentioned in their 
capabiUty lists. Applications can also include their own capability filtering criteria 
by including additional 'RequiredCapabilities'. For example, an application may 
only include components provided by a particular vendor. If locating such 
components fails, then the requirement Usts could be changed by the appUcation 
and retried using the algorithm. 

Exemplary Profiles and Operations For Multiplexer / Enco ding applications 

[0086] Encoding applications usually imply a specific arrangement 
structure, illustrated in Fig. 9. Typically there is a multiplexer device 910 which 
receives compressed streams and multiplexes them together (i.e., the multiplexer 
alternates the input streams while ensuring time stamping and format specific 
buffering restrictions are met). There are one or more inputs to the multiplexer. 
Typically these are supplied by one or more video encoders 900 and audio 905 
encoders. 

[0087] In an exemplary implementation a profile, associated settings and 
usage semantics may be designed such that an encoder topology can be built and 
configured from a generic encoding profile. The topology in Fig. 9 may be 
constructed from the multiplexer to the encoders. The profile may be designed 
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such that there is an identifiable subprofile for the multiplexer from the profile's 
N+1 subprofiles. 

[0088] In an exemplary implementation, the topology may be built and 
configured using the following operations. The output filter/device is created, as 
described above. A partial encoding topology is constructed, e.g., by selecting the 
multiplexer using the selection procedures described above. The multiplexer is 
configured using the subprofile associated with the operation, including the 
number of input streams, and connected to the output of the encoders. For each 
multiplexer input, which corresponds to each of the N subprofiles (excluding the 
multiplexer subprofile), an encoder is selected, e.g., using the selection algorithm 
described above, configured using the subprofile settings, and connected to the 
multiplexer's input. The media's video and audio sources may then be created and 
the sources may be connected to the topology, e.g., using connection algorithms 
provided in DIRECTSHOW. 

[0089] Although the described arrangements and procedures to reconcile 
file systems interconnected components have been described in language specific 
to structural features and/or mediodological operations, it is to be understood that 
the subject matter defined in the appended claims is not necessarily limited to the 
specific features or operations described. Rather, the specific features and 
operations are disclosed as preferred forms of implementing the claimed present 
subject matter. 
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